Mobile telecommunications network typically includes a radio access network connected to core network 100 as illustrated in FIG. 1. The core network 100 can be interconnected with other networks and the radio access network comprises radio base stations 130a-130d, each configured to communicate over the radio interface with mobile terminals 150 located in the cell served by the respective radio base station.
At the cell-edge, the mobile terminals are sometimes power-limited, i.e. their transmission power is not sufficient to reach the targeted transmission error rate, the so-called block error rate. It is therefore a need to find a solution for enhancing the coverage for power-limited mobile terminals. HARQ (Hybrid Automatic Repeat reQuest) is a well-known technique to mitigate such situations.
Automatic Repeat reQuest (ARQ) is an error control method for data transmission which uses acknowledgments and timeouts to achieve reliable data transmission. An acknowledgment is a message sent by the receiver to the transmitter to indicate that it has correctly received a data frame or packet. A timeout is a reasonable point in time after the sender sends the frame/packet. If the sender does not receive an acknowledgment before the timeout, it usually re-transmits the frame/packet until it receives an acknowledgment or exceeds a predefined number of re-transmissions. A variation of ARQ is Hybrid ARQ (HARQ) which has better performance, particularly over wireless channels.
HARQ operation modes can use incremental redundancy and Chase combining. By using HARQ, the user data can be transmitted multiple times. For each transmission or retransmission either the same (Chase combining) or potentially a different redundancy version (incremental redundancy) is sent. When a corrupted packet is received, the receiver saves the soft information, requests a retransmission by sending a negative acknowledgement and later combines it with the already received soft information with the soft information conveyed in the retransmissions to recover the error-free packet as efficiently as possible. By doing so it essentially accumulates the energy of all transmissions and retransmissions. Typically, after a few HARQ retransmissions the data is successfully received.
Consequently, a HARQ process takes care of the transmission of the first transmission and potential retransmissions at the sender side and the corresponding reception at the receiver side. In addition, the sender side process interprets the HARQ feedback and the receiver side generates the corresponding HARQ feedback according to the reception state.
If the number of retransmissions that is required for a successful transmission is growing, the retransmission delay is also increasing proportionally. For every retransmission round one HARQ Round Trip Time (RTT) is required. For some applications only a certain delay is acceptable. If such delay bounds need to be kept, alternative approaches are needed.
Another problem of the approach above is that the HARQ feedback is typically quite sensitive, since often only a single bit is used for ACK or NACK. Assuming that 9 retransmissions are needed and the HARQ feedback error rate is 10−3, this results in an overall probability that at least one of the HARQ feedback is subject to a NACK-ACK error of roughly 10−2. Since such NACK-ACK error leads to a data packet loss, unless another retransmission protocol is used in addition to HARQ, a large number of required HARQ retransmissions might lead to unacceptable packet loss rates for certain applications. For example, 10−2 is often mentioned as packet loss requirement for Voice over IP applications, i.e. less than 10−2 IP packet should be lost to maintain an acceptable voice quality.
One state-of-the-art approach to reduce the number of HARQ retransmissions of a single HARQ process is segmentation at L2, which is illustrated in FIG. 2. In this solution user data is segmented in smaller portions that are then transmitted in independent HARQ processes. I.e. each segment is subject for a HARQ feedback. Although this solution reduces the risk of a HARQ feedback failure for a single process, it does not reduce the probability of an IP packet loss, since all HARQ processes that carry a segment of the IP packet need to be received correctly. In total, the probability for a HARQ feedback failure is therefore in the same order.
Example: Instead of sending 264 bits of user data in one HARQ process, the user data might be split up in 4 parts leading to 4 HARQ processes with 66 bits each. In the original case 16 HARQ transmissions might be needed. For the L2 segmentation case, this would correspond to 4 HARQ transmissions for each process. These are in total still 16 transmissions. However, they can be parallelized, since in state-of-the-art systems, several HARQ processes can be active at the same time. Thus, the transmission delay can be reduced by L2 segmentation.
However, the above described approach has the disadvantage that the L2 protocol headers (e.g. MAC and RLC) that are needed to describe the user data (e.g. Sequence Number, length) and the segmentation (segmentation flags, segment length in LTE) grows with increasing number of segments. In addition, typically L1 adds a checksum. Thus additional overhead is introduced.